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PROCESSING NETWORK ADDRESS IDENTIFIERS 



This invention relates to a method of operating a communications network. 

5 The Session Initiation Protocol (SIP) is an application-layer control protocol for 

creating, modifying and terminating sessions having one or more participants. These 
sessions include internet multimedia conferences, Internet telephone calls and 
multimedia distribution. Members in a session can communicate via multicast or via a 
mesh of unicast relations, or a combination of these. SIP supports session 
10 descriptions that allow participants to agree on a set of compatible media types. It 
also supports user mobility by proxying and redirecting requests to the user's current 
location. SIP is not tied to any particular conference control protocol. There is 
widespread interest in the protocol, especially for telephony-related applications. SIP 
was proposed by the Internet Engineering Task Force (IETF) group and is now a 
1 5 proposed standard published as RFC 2543. 

The entities used in SIP are user agents, proxy servers, redirect servers and 
location servers. A SIP user agent is an end-system that allows a user to participate 
in a session. A SIP user agent contains both a user agent client and a user agent 
server. A user agent client is used to initiate a session and a user agent server is used 
20 to respond to request from a user agent client. A user is addressed using an email-like 
address identifier "user@host", where "user" is a user name or phone number and 
"host" is a domain name or numerical Internet Protocol (IP) address: SIP' defines a 
number of request types, in particular INVITE, ACK, BYE, OPTIONS, CANCEL, and 
REGISTER. Responses to SIP messages indicate success or failure, distinguished by 
25 status codes, 1xx (100 to 199) for progress updates, 2xx for success, 3xx for 
redirection, and higher numbers for failure. Each new SIP transaction has a unique 
call identifier (call ID), which identifies the session. If the session needs to be 
modified, e.g. for adding another media, the same call identifier is used as in the 
initial request, in order to indicate that this is a modification of an existing session. 
30 Tne SIP user agent has two basic functions: listening for incoming SIP 

messages, and sending SIP messages upon user actions or incoming messages. The 
SIP user agent typically also starts appropriate applications according to the session 
that has been established. A SIP proxy server can relay SIP messages - it is possible 
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to use a domain name to find a SIP proxy server, for example using the Domain Name 
System (DNS), rather than knowing the IP address or name of the host. A SIP proxy 
can thereby also be used to hide the location of the user. A redirect server returns 
the location of the host rather than relaying the SIP message. Both redirect and proxy 
servers accept registrations from users, in which the current location of the user is 
given. The user's location can be stored at a dedicated location server. 

SIP is typically implemented by transmitting Internet Protocol (IP) packets. 
SIP is independent of the packet layer and only requires an unreliable datagram 
service, as it provides its own reliability mechanism. While SIP typically is used over 
UDP or TCP, it could be used over frame relay, ATM AAL5 or X.25. 

SIP is a text based protocol and is based to a certain extent (in terms of 
syntax) on the HTTP protocol." A typical message consists of a single request line, a 
number of header lines and a message body. 

The request line indicates the type of the messages, the message destination 
and the SIP version it complies with. The following is a typical example: 

INVITE sip:Richard@bt.com SIP/2.0 

A header line contains the name of the header type, followed by a semicolon 
and the contents as these are defined for the specific header. Consequently, each 
header type is used for a specific purpose (either to indicate some parameters or to 
issue a request). The following are typical examples: 

From: sip:Richard@bt.com 

To: sip:Steve@bt.com 

Subject: Official meeting 

The message body may be of any content, although it usually has contents 
formatted in accordance with the Session Description Protocol (SDP). 

SIP URL address identifiers such as sip:Richard@bt.com are required for the 
exchange of SIP messages in a similar way that e-mail URL address identifiers are 
required for the exchange of electronic mail. 

By using an e-mail type address it is possible to deliver a SIP message to a 
SIP server that knows the location of the user or user agent server the message is 
intended for. The IP address of the SIP server having authority for the callee's 
address can be readily determined by DNS. 



WO 01/74029 



PCT/GB01/01331 



The above referenced proposed standard, RFC 2543, encourages implementers of SIP 
services to name SIP servers by appending the string 'sip.' to their domain name. It 
is further suggested that an implementation might derive an address for use in SIP 
communications from the intended recipient's e-mail address. The proposed method 
5 of derivation is to add the prefix 'sip.' to the host part of the intended recipient's e- 
mail address (e-mail addresses normally being of the form 'user@host'). 

According to an aspect of the present invention there is provided a method of 
operating a network to provide communications in accordance with a first 
communications protocol, said method comprising: 
10 receiving a base address identifier convertible by a first directory server 

associated with said network to an address for use in communications made in 
accordance with a second communications protocol; 

derive, from said base address identifier, an amended address identifier 
convertible by a second directory server to an address for use in communications 
1 5 made in accordance with said first communications protocol; 

wherein at least part of said address identifiers is formed in accordance with 
a hierarchical addressing scheme, said part comprising a sequence of address 
identifier components, the position of a component in said sequence indicating the 
level of said component in said hierarchical addressing scheme; 
20 said method being characterised in that said derivation involves introducing 

amended address components so that a plurality of base address identifiers 
convertible by said first directory server are converted to one or more amended 
address identifiers convertible by said second directory server. 

In this way, it is possible to derive unique address identifiers for new 
25 communications services to be provided over a newly implemented communications 
protocol from respective address identifiers provided for services associated with a 
fully implemented communications protocol. The above method provides for a new 
address space to be created for use with DNS or other address resolution systems for 
the provision of communication services associated with a newly available 
30 communications protocol. The invention also provides for translation between address 
spaces. For instance, if a message is sent but not delivered to a user or location 
identified by an address identifier generated in accordance with the above method, 
the address identifier can be resolved back to its respective original address identifier 
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and the message sent to the location associated with that original address by means 
of a service available over the first communications protocol. In this respect, address 
resolution is readily achievable since the respective first and second address 
identifiers are directly derivable from one another. This avoids the usual requirement 
5 of providing and maintaining of a costly address database for mapping respective first 
and second address identifiers. Another advantage of the above method is that the 
address space is readily scalable. For instance, by using the domain name hierarchy 
associated with the first communications protocol a new domain name hierarchy can 
be created and integrated, if appropriate, with DNS. A further advantage of the above 

10 method is that users can readily address messages etc, for transmission over one 
communications protocol using an address identifier associated with another 
communication protocol. The ability to make use of the address space associated 
with a widely implemented communications protocol is very important when, say, 
new services are to be introduced using a new protocol. For example, a user may 

1 5 address a message to another user using a new address identifier derived from a 
known identifier regardless of whether the user is aware of the recipient's address 
identifier for the newly introduced protocol or whether the recipient has indeed been 
allocated a new address identifier or is capable of receiving the message over the 
new protocol. The user sending the message only requires knowledge of the 

20 recipient's address identifier associated with the widely implemented protocol. 

In contrast to the RFC 2543 proposal of adding an address component at the 
lowest level of the domain name hierarchy, the present invention provides address 
components at a higher level than the lowest level component in the known e-mail 
address, The entries in the directory can be concentrated in the directory server 

25 associated with the level of the hierarchy that corresponds to the added address 
component. Where, as is normally the case, there are a plurality of instances of 
address components below the added address component, this enables the directory 
service for the first communications service to be provided by a single directory 
server rather than a plurality of directory servers. 

30 Preferably, at least one of said one or more address components is positioned 

in said sequence such that in said amended address identifier, said one or more added 
address components are associated with higher positions in said hierarchy than the 
address components derived from said base address identifier. 
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This has the advantage that all directory enquiries can be handled by a 
directory server under the control of a party introducing said first communications 
service. 

In some embodiments, the base address identifier components are removed 
5 and replaced by amended address identifier components. However, in preferred 
embodiments, one or more base address components are maintained in said amended 
address identifier. This allows address hierarchies which have evolved in relation to 
the base address identifier to be re-used in the provision of the second 
communications protocol. 

10 lf a " the components of the base address identifier are maintained in the 

amended address identifier, then this gives the advantage that an address (e.g. an e- 
mail address) which is known to be unique in relation to the second communications 
protocol is also known to be unique in relation to the first communications protocol. 
In addition, the base address identifier can be re-created from the amended address 

15 identifier, thus allowing the second directory server to revert to the second 
communications protocol if desired and forward a message intended to be sent in 
accordance with the first communications protocol in accordance with the second 
communications protocol instead. This allows, for example, the second directory 
server, on receiving a SIP message for which it is unable to provide an address, to 
20 instead send an e-mail to the intended recipient indicated that it has been unable to 
provide a SIP connection through to the recipient. 

According to another aspect of the present invention, there is provided a 
method of generating address identifiers for use in a communications network; said 
method comprising the steps of:- 

25 processing a first address identifier constructed in accordance with a first 

communications protocol; and, 

constructing a second address identifier, from said first identifier, in 
accordance with a second communications protocol. 

30 Preferably, said first identifier is processed in accordance with a pre- 

determined set of rules to provide said second identifier. 

Conveniently, said first identifier comprises at least one address component 
and said second identifier comprises at least one address component of said first 
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identifier. In this way address components can be common to both first and second 
address identifiers. 

In preferred embodiments, said second identifier includes each address 
component of said first identifier. This simplifies address translation and allows users 
5 to intuitively derive one address identifier from the other identifier. This enhances the 
integration of services provided over a newly introduced communications protocol 
with services provided over an existing communications protocol. 

Preferably, said step of constructing said second identifier comprises the step 
of adding one or more address components to said first identifier. This enhances the 
10 above mentioned advantages. 

Conveniently, said method comprises the steps of adding at least one prefix 
address component and at least one suffix address component to said first identifier. 
This provides for the addition of at least two further distinguishing address 
components. 

1 5 In preferred embodiments, said prefix address component is representative of 

the second communications protocol and said suffix component is representative of a 
network domain associated with said second network communications protocol. This 
allows users to identify the communications protocol that is associated with the 
newly generated address identifier and the network domain authority for that address 

20 identifier. 

Preferably, said second communications protocol is an application layer 
control protocol. This provides for the implementation of user applications and new 
communications services over said communications protocol. 

Conveniently, the control protocol conforms to Session Initiation Protocol. 

25 Thus SIP messages can be addressed to an existing address identifier, for example 
and e-mail address identifier constructed in accordance with Simple Mail Transfer- 
Protocol (SMTP), and translated to a corresponding SIP address identifier for 
transmission to a SIP user agent server regardless of whether the SIP address 
identifier is known to the user. Thus, the present invention enables messages to be 

30 readily diverted from a SIP defined destination URL address identifier to a 
corresponding SMTP defined destination URL address identifier for the same user or 
end system. In this way users may send SIP messages to SMTP address identifiers 
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using the SMTP network protocol and infrastructure and SMTP messages to SIP 
address identifiers using the SIP network protocol and infrastructure. 

In preferred embodiments, a software program is arranged to implement the 
method according to the above-described aspect of the invention. 
5 According to another aspect of the invention there is provided a system for 

generating address identifiers for use in a communications network; said system 
comprising;- 

a processor for processing a first address identifier constructed in accordance 
with a first communications protocol; and,. 
10 an address identifier constructor for constructing a second address identifier, 

from said first identifier, in accordance with a second communications protocol. 

The invention will now be described with reference to the accompanying 
drawings in which:- 

Figure 1a is a schematic representation of a typical SIP message signalling 
1 5 sequence in a network comprising a SIP re-direct server; 

Figure 1 b is a schematic representation of a typical SIP message signalling 
sequence in a network comprising a SIP proxy se>ver; 

Figure 2 is a block diagram of a SIP user agent; 

Figure 3 is a block diagram of a SIP user agent graphical user interface; 
20 Figure 4 is a schematic representation of a communications network 

comprising a plurality of SIP enabled network domains; and, 

Figure 5 is a flow diagram of a method implemented in the communications 
network of Figure 4; 

With reference to the drawings, typical signalling sequences are shown in 
25 Figures 1a and 1b between two user agents 100 and 102 connected over a 
communications network using a SIP redirect server 106 (figure 1a), and a SIP proxy 
server 108 (Figure 1b). In both arrangements a SIP location server 110 is connected 
to the respective SIP network server for address resolution. 

In Figure 1a, user agent 100 sends a SIP Invite message 112 to user agent 
30 102. The Invite message is received at and processed by the re-direct server 106 to 
determine the network location of user agent 102. The re-direct server sends a 
location query 114 to the location server 110. The location server determines the 
current network location of user agent 102 and sends this information to the re-direct 
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server in a message 116 for transmission to the user agent 100 in a message 1 18. 
User agent 100 then sends an Invite message 120 to user agent 102, either directly 
or via other SIP re-direct or proxy servers, which then responds by sending an 
acceptance message 122 to the user agent 100. User agent 100 completes the 
5 session or call set up procedure by sending an acknowledgement 124. Once the 
session has been set up information can be exchanged between the respective user 
agents. 

In Figure 1b, user agent 100 sends a SIP Invite message 126 to user agent 
102 as before but instead of being processed by a re-direct server the message is 

10 processed by the network proxy server 108. The proxy server sends a location query 
128 to the location server 110. The location server determines the current network 
location of the user agent 102 and sends this information back to the proxy server in 
a message 130. The proxy server then relays the Invite message to the user agent 
102 by means of a message 132 which is processed by the user agent 102. A call 

15 acceptance message 134 is then sent back to the proxy server which relays a 
corresponding message 136 to the user agent 100. The user agent 100 then sends 
an acknowledgement message 138 to the proxy server which similarly relays a 
corresponding message 140 to the user agent 102. 

With reference now to Figure 2, a typical SIP user agent 200 comprises a 

20 front end system in the form of a graphical user interface (GUI) 202, a SIP client 
program 204, a SIP server program 206, a media module 208, a network interface 
210 a SIP address cache 212, a SIP URL address generator 214 and a SIP message 
processor 21 6. 

A typical SIP GUI is shown in Figure 3. The GUI 202 comprises a plurality of 
25 buttons 302 to 31.0 each of which represents a different SIP request method. Button 
302 represents the*SIP "INVITE" request for inviting a callee to a SIP session, button 
304 represents the "OPTIONS" request for discovering the capabilities of the 
receiving terminal, button 306 represents the "BYE" request for terminating a call or 
a call request, button 308 represents the "CANCEL" request for terminating 
30 incomplete call requests and button 310 represents the "REGISTER" request method 
for registering the current location of the user with a respective domain location 
database 110. The respective request methods are invoked by a user clicking the 
respective button, by mouse controlled cursor click or otherwise. The GUI further 
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comprises a text box 314 labelled "To: SIP URL" for user input, by keyboard entry or 
address book entry selection for example, of the SIP address identifier of an intended 
callee, that is to say the SIP destination message header field "To"; a text box 316 
labelled "To: e-mail URL" for user input of the e-mail address identifier of the intended 
5 callee; and, a text box 318 labelled "Title" for displaying title information to identify 
the session. A further text box 320 is provided for the input of other SIP message 
text including for example other SIP header types and text comprising the SIP 
message body. Text may be input into any one of the text boxes 314, 316, 318, 320 
using known text processing means, for example, keyboard entry, selection from pull 
10 down menus or cut and paste text processing applications. 

The SIP message constructor is configured to process data entered into any 
one of the boxes 314, 316, 320, 320 and construct a SIP message including the 
relevant request type for transmission to an appropriate SIP network server. For 
example, the message constructor copies the text entered in the text box 314 to the 
15 SIP message header type "To:" in the SIP message being constructed. Other header 
types are determined by the message constructor such as "Content-type:" and 
"Content length:" for example . 

The user agent client program is configured to initiate a SIP session or "call" 
and the user agent server program is configured to respond to a call. In this regard 
20 the user agent client program implements the SIP request methods Invite, Options, 
Bye, Cancel and Register, and the user agent server implements the methods Invite, 
Bye, Cancel and Ack methods. Messages are passed from the user agent client to the 
network interface 210 for transmission to the intended callee associated with the 
destination SIP URL address. SIP messages are received at the destination end by the 
v 25 network interface and are processing by the user agent server. The media module 
208 provides the necessary API's for sending system calls to appropriate media 
applications for processing different media types once a SIP session has been 
established. 

When a user wishes to initiate a SIP session, the user interacts with the GUI 
30 202 to construct a SIP Invite message including a destination SIP or e-mail address. 
Once all the necessary data has been input to the GUI, including the SIP header types 
and message body, the message processor constructs an appropriate SIP message for 
transmission to the callee. In the event that the callee's SIP URL address is unknown 
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to the user, the user inputs the callee's SMTP e-mail address in the text box 316. The 
e-mail address is then sent to the SIP URL generator 214. 

The SIP URL generator 214 comprises a software program for generating a 
SIP URL address identifier from a respective SMTP e-mail address identifier for a 
5 respective user. 

The SIP URL generator is configured to process the e-mail address identifier, 
in accordance with a set of pre-determined rules, to generate a corresponding SIP 
URL address identifier for the callee. In one arrangement, the e-mail address is 
processed by the SIP URL generator which adds a prefix address component to the 

10 existing e-mail address components "user@host" etc. The prefix address component 
identifies the communications protocol that the new URL is to be used with. In this 
embodiment ''sip" is added as a prefix. A suffix address component is also added to 
identify a SIP domain name authority the newly generated SIP URL address identifier 
is to be identified with. In one example the SIP URL generator is configured to 

15 process the SMTP e-mail address "alan.oneill@bt.com" to derive the SIP URL address 
identifier "sipralan. oneill@bt.com. sipit.com", that is to say, to add the protocol prefix 
"sip" and the domain suffix "sipit.com" to the existing SMTP readable e-mail address 
"alan.oneill@bt.com". Thus, the SIP URL generator is configured to generate SIP URL 
address identifiers by processing a respective address identifier constructed in 

20 accordance with the Internet e-mail communications protocol SMTP. In another 
example the SIP URL generator is configured to process the same SMTP e-mail 
address identifier to derive the SIP URL address identifier 
"sip:alan. oneiII@bt.com. uk.sipit.com", that is to say a geographical identifier "uk" is 
additionally added to the SMTP e-mail address identifier. The additional geographic 

25 identifier may assist scalability of the name space and hence network routing 
efficiency of the resulting SIP message, for example. 

Referring now to Figure 4, a plurality of network domains 400, 402 and 404 
are each connected to the Internet 406 by means of a respective SIP network server 
408, 410 and 412. In the network of Figure 4 the SIP network servers are configured 

30 for use both as SIP proxy and SIP re-direct servers. The SIP network servers provide 
access to and from the respective domains. Each network domain comprises a 
plurality of SIP user agents 200(a-g). SIP user agents 200a, 200b and 200c are 
connected to the network server 408 in the domain 400, SIP user agents 200d, and 
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200e are connected to the network server 410 in the domain 402, and SIP user 
agents 200f and 200g are connected to the network server 412 in the domain 404. 
Each SIP network server is connected to a respective location server 110 for SIP 
address resolution and an associated SIP to SMTP e-mail gateway 414. Each SMTP e- 
5 mail gateway is connected to a respective SMTP Mail Transfer Agent (MTA) 416 for 
relaying SMTP e-mail messages to respective destination SMTP MTA's over transport 
layer TCP connections. 

Each SIP to SMTP e-mail gateway 414 comprises an SMTP e-mail address 
generator 418 and a message processor 420 which comprises an SMTP user agent. 
0 The e-mail address generator comprises software for generating an SMTP address 
identifier from a SIP URL address identifier. In this regard the e-mail address generator 
is configured in a similar but reverse manner to the address generator 214. The e-mail 
address generator is configured to process the SIP URL destination address identifier 
of an out going SIP message to derive a corresponding SMTP e-mail address 
5 identifier. The e-mail address generator processes the SIP URL address in accordance 
with the same pre-determined set of rules as the SIP address generator 214, but 
processes these rules in reverse order with respect to the address generator 214. For 
instance, in one embodiment a SIP message arriving at the SIP to SMTP e-mail 
gateway 414 is parsed to determine the destination SIP URL. The SIP URL is then 
0 passed to the SIP to e-mail address generator 418. The remaining part of the SIP 
message is re-formatted by the message processor 420 into SMTP format suitable for 
transmission as an SMTP e-mail message. 

In one embodiment the address generator 418 is programmed' in accordance 
with the above set of rules, that is to say to remove the protocol identifier prefix 
"sip" from the SIP URL address and to remove the sip domain suffix component 
"sipit.com". The address generator sends the re-formatted SMTP address identifier to 
the message processor where the newly derived SMTP address is added to the re- 
formatted message as the destination SMTP address for that message. The message 
processor adds the newly generated SMTP address to the SMTP "To:" header field of 
a respective SMTP message. For example, the address generator 418 is programmed 
to derive the SMTP e-mail address identifier alan.oneill@bt.com from SIP URL 
"sip:alan. oneill@bt.com. sipit.com". 
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The message processor 420 constructs an appropriate SMTP message for 
transmission to the newly generated SMTP address according to the content of the 
respective SIP control message. For example, the SIP message payload, for example 
the SDP message component of the SIP message , is added as text to the respective 
5 SMTP message body for transmission to the respective destination SMTP address. In 
the example described with reference to Figure 3, the SDP text shown in box 320 is 
processed and added as text to the SMPT message payload by the message 
processor 420. 

With reference now to the flow diagram of Figure 5, a user initiates a SIP 

10 session in step 500 by interaction with the GUI 202 of a SIP user agent 200. A data 
entry for each of the required data types is input by the user including a destination 
SIP address in box 314 or, in the absence of a known SIP URL for the intended 
recipient, an SMTP e-mail address that is known to be allocated to the recipient in 
box 316. Data relating to the SIP message is processed into SIP format by the SIP 

15 message processor 216 and is then submitted to the user agent client 204 by the 
user selecting the Invite button 302 by mouse click or other data input command. The 
user agent client determines in step 502 whether a SIP URL address has been 
provided or an SMTP e-mail address. If a SIP URL has been provided processing 
proceeds to step 508. However, if an SMTP e-mail address identifier has been 

20 provided the user agent client sends the e-mail address to the address generator 214 
for processing to a respective SIP URL address identifier in step 504. A respective SIP 
URL is generated in accordance with the above described method. In step 506 the 
newly derived SIP URL address is added to the SIP destination header type "To:" 
following the INVITE request type of the SIP message. 

25 The SIP message is transmitted to the appropriate local SIP network server 

408,410 or 412 in step 50S to be relayed or re-directed to a network server 
associated with the destination SIP URL address. The network server that receives 
the SIP message queries its associated location database 1 10 in step 510, using DNS 
or other address resolution means, to determine the network server the SIP message 

30 should be transmitted to. In step 512 a network server having authority for the 
domain for the destination SIP URL determines whether the destination SIP URL 
address is a valid network address, that is to say, whether the SIP URL address has 
been allocated by the domain authority to a SIP user. The SIP URL destination 
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address is a valid network address if it can be resolved by a location database using 
DNS or other resolution means to a respective numerical IP address, for example. In 
this respect address resolution may involve querying other location databases 
associated with other network SIP servers or SIP domains in a similar way that DNS 
resolves numerical IP addresses. In step 514, if "the destination SIP URL address is 
valid, that is to say it has been allocated to a respective user and can be resolved, the 
location server returns the IP address of the next SIP server that is configured to relay 
or re-direct the message or if appropriate the IP address of the end system currently 
associated with the destination SIP URL. The SIP message is sent to the next SIP 
network server or destination end system in step 51 6. If the SIP URL is invalid, that is 
to say it has not been allocated by the appropriate domain authority for use in the 
network, an appropriate SIP network server transmits the SIP message to an 
associated SIP to SMTP e-mail gateway in step 516. The destination SIP URL may be 
invalid for instance because it was automatically generated from a known e-mail 
address identifier in step 504 and no corresponding SIP address exists. Under these 
circumstances the message processor 420 re-formats the SIP message to an SMTP 
message for communication over the Internet 406 in accordance with SMTP in step 
518. In step 520 the destination SIP URL address is processed by the address 
generator 418 in step 520 to derive the SMTP e-mail address encapsulated within the 
SIP URL address. Additional information and data is added to the re-formatted SMTP 
e-mail message in step 522 including, for example the text:- 

"You were called by SIP user < sender's SIP URL and associated data> at 
<time, date> with message < SIP message body content (SDP) > but 
you were not found in the SIP registration system. You can register at 
<http hyperlink> where you can download a SIP client." 

or, 

"You were called by SIP user < sender's SIP URL and associated data> at 
<time, date> with message <SIP message body content (SDP)> but you 
were not found in the SIP registration system. You can register using the 
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attached http form <http registration form with mailto: URI address >. A 
SIP client <SIP client executable code> is attached." 

The SMTP message is sent to an associated mail transfer agent 416 in step 
5 524 for transmission to the e-mail address derived in step 520 using the SMTP 
network protocol. In step 526 the sender is informed by the SIP server that the 
destination SIP URL was not valid and that the message was instead re-formatted 
according to SMTP and sent to the SMTP e-mail address derived in step 520. 

it will be seen that the other embodiments of the present invention could be 

10 readily implemented by the skilled person, for instance instead of the SIP message 
being diverted to a SIP to e-mail gateway in the event that the destination SIP URL 
address is invalid, a SIP message could be readily diverted to a SIP to e-mail gateway 
if the user or the end system associated with the user was unavailable or unwilling to 
receive SIP messages at the time of message transmission. In one embodiment, the 

15 respective SIP server selects an appropriate message from an associated message 
library (not shown) for inclusion with the original SIP message in step 522. The 
message library includes a respective delivery failure message for each SIP message 
delivery failure mode, including for example, destination SIP user agent unavailable, 
user unavailable, network connection failure, user unwilling to join SIP session or user 

20 unwilling to join designated sessions, user will be available at <time, date>, etc. 

It will also be seen that in other embodiments the SIP to e-mail gateway 414 
could be readily implemented in other network devices such as a respective network 
SIP server or a SIP user agent. 

25 



WO 01/74029 PCT/GB01/01331 

15 



CLAIMS 

1 . A method of operating a network to provide communications in accordance 

with a first communications protocol, said method comprising: 
5 receiving a base address identifier convertible by a first directory server 

associated with said network to an address for use in communications made in 

accordance with a second communications protocol; 

derive, from said base address identifier, an amended address identifier 

convertible by a second directory server to an address for use in communications 
10 made in accordance with said first communications protocol; 

wherein at least part of said address identifiers is formed in accordance with 

a hierarchical addressing scheme, said part comprising a sequence of address 

identifier components, the position of a component in said sequence indicating the 

level of said component in said hierarchical addressing scheme; 
15 said method being characterised in that said derivation involves providing 

amended address components so that a plurality of base address identifiers 

convertible by said first directory server are converted to one or more amended 

address identifiers convertible by said second directory server. 

20 2. A method according to claim 1 wherein at least one of said one or more 
address components is positioned in said sequence such that in said amended 
address identifier, said one or more added address components are associated with 
higher positions in said hierarchy than the address components derived from said base 
address identifier. 

25 

3. A method according to claim 1 jn which one or more of said base address 
identifier components are maintained in said amended address identifier. 

4. A method according to claim 3 in which all of said base address identifier 
30 components are maintained in said amended address identifier. 
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